Thanks for working on this @Zelys-DFKH — this addresses a real pain point. I filed the original issue (#2240) and have been thinking about the design here, especially considering future graph looping support (revisiting previous nodes via edge conditions).

Proposal: Introduce two distinct statuses — SKIPPED and CANCELLED

After looking at how the TypeScript Strands SDK and LangGraph handle this, I think we should distinguish between two semantics:

1. SKIPPED — skip this node, continue downstream (what this PR does)

This is the "skip and continue" semantic. The node is intentionally bypassed, but downstream dependents should still execute. This is what my bug report asks for.

Design:

• Introduce Status.SKIPPED enum value (not COMPLETED — a node that never ran shouldn't be marked as completed)
• Dependency resolution treats SKIPPED the same as COMPLETED — the node counts as "satisfied" for downstream readiness checks in _find_newly_ready_nodes / _is_node_ready_for_resume
• _build_node_input should skip the header entirely for SKIPPED deps (no empty "From node_x:" with nothing underneath)
• reset_on_revisit clears SKIPPED nodes (same as COMPLETED) — they become eligible for execution again on loop re-entry
• The NodeResult should not store a RuntimeError — a skipped node isn't an error. Use a lightweight marker (e.g., None result or a dedicated sentinel) so get_agent_results() cleanly returns []

The SKIPPED status is valuable because:

• It's semantically honest — a node that never ran isn't "completed"
• Edge conditions on outgoing edges can inspect execution_status == SKIPPED vs COMPLETED and route differently (powerful for loop control)
• Observability — dashboards/logs can distinguish "ran successfully" from "intentionally bypassed"
• No ambiguity with nodes that ran but legitimately returned empty output

2. CANCELLED — kill this branch gracefully (align with TS SDK)

This is what the TypeScript SDK does with beforeEvent.cancel: the node is cancelled, marked as a terminus, and downstream nodes do NOT execute. No error propagates — the graph can still complete via other branches.

This could be a separate hook field (e.g., cancel_node for cancel, skip_node for skip) or a single field with enum values ("skip" vs "cancel").

Why both are needed (especially for looping)

Consider a loop: A → B → C → (edge back to A if condition)

• SKIPPED: On iteration 2, B is skipped because it already gathered data. C still runs, the back-edge fires, and the loop continues. This is the common case for conditional execution within loops.
• CANCELLED: You want to abort a branch entirely — e.g., an optional side-branch that's no longer relevant. The main loop path continues via other branches.

Without the distinction, you can't express "skip but continue" vs "stop this path" — both of which are legitimate control flow decisions.

Complementary mechanism: Edge conditions with invocation_state

PR #2305 (merged) added invocation_state to edge condition evaluation, which provides an alternative way to route around nodes at the edge level. The two mechanisms are complementary:

• Edge conditions: Control whether to traverse a path (node never enters the execution batch)
• skip_node / cancel_node hooks: Control whether to execute a node that's already been reached (node is in the batch but gets bypassed)

Both are needed because edge conditions are evaluated before batch formation, while hooks fire after.

Happy to collaborate on the implementation if this direction makes sense. The core of your PR is right — the change from "raise RuntimeError" to "return cleanly" is exactly the fix. The suggestion is to layer proper status semantics on top.

Agreed on SKIPPED vs COMPLETED. Updated; your analysis of the header-leak risk in _build_node_input was spot-on, too.

result=None, Status.SKIPPED throughout. _build_node_input filters SKIPPED deps before building dependency_results, so when all upstream deps are skipped the downstream node gets just the original task with no orphaned "From step_a:" header. _from_dict reads the persisted NodeResult.status to restore Status.SKIPPED correctly on resume. Also added skipped_nodes to GraphResult and adjusted completed_nodes to exclude SKIPPED nodes, which closes the observability gap.

SKIPPED nodes live in completed_nodes rather than a separate set. That satisfies both _find_newly_ready_nodes and _compute_ready_nodes_for_resume without touching either function. reset_on_revisit works correctly for loop re-entry, too: SKIPPED nodes are in completed_nodes, so they get cleared and become eligible for execution again on the next iteration.

edge.should_traverse is still evaluated for outgoing edges of SKIPPED nodes, which preserves the division you described: edge conditions control whether to enter a path before batch formation, hooks control whether to execute after.

CANCELLED (abort-branch semantics) is a separate concern; I'll open an issue.

Opened #2401 to track CANCELLED (abort-branch semantics). It also surfaces the cancel_node → skip_node naming question — happy to make that rename in this PR if maintainers prefer Option A before it merges.

Do you mind rebasing? I am asking Strands team to review

Assessment: Request Changes

The core fix is sound — replacing RuntimeError propagation with Status.SKIPPED is the right approach, and the dependency filtering/resume logic is well-implemented. However, there's a critical test/source mismatch that will cause CI failures.

Good work on the _build_node_input filtering, _from_dict status restoration, and thorough test coverage for the new skip_node path.